home *** CD-ROM | disk | FTP | other *** search
/ EnigmA Amiga Run 1995 November / EnigmA AMIGA RUN 02 (1995)(G.R. Edizioni)(IT)[!][issue 1995-11][Skylink CD].iso / earcd / program / amos / amoslist.lzh / AMOSLIST / 000071_amos-request@svcs1.digex.net_Mon Sep 4 08:54:46 1995.msg < prev    next >
Internet Message Format  |  1995-10-02  |  4KB
  1. Received: from svcs1.digex.net (svcs1.digex.net [204.91.197.224]) by mail1.access.digex.net (8.6.12/8.6.12) with ESMTP id IAA16614;  for <mcox@access.digex.net> ; Mon, 4 Sep 1995 08:54:45 -0400
  2. Received: (from daemon@localhost) by svcs1.digex.net (8.6.12/8.6.12) id GAA17199 for amos-out; Mon, 4 Sep 1995 06:28:59 -0400
  3. Received: from mail1.access.digex.net (mail1.access.digex.net [205.197.247.2]) by svcs1.digex.net (8.6.12/8.6.12) with ESMTP id GAA17196 for <amos-list@svcs1.digex.net>; Mon, 4 Sep 1995 06:28:58 -0400
  4. Received: from wn1.sci.kun.nl (wn1.sci.kun.nl [131.174.8.1]) by mail1.access.digex.net (8.6.12/8.6.12) with ESMTP id GAA12259;  for <amos-list@access.digex.net> ; Mon, 4 Sep 1995 06:26:51 -0400
  5. Received: from mpih17 by wn1.sci.kun.nl via mpih17.mpi.nl [192.87.79.57] with SMTP 
  6.     id MAA00250 (8.6.10/2.13) for <amos-list@access.digex.net>; Mon, 4 Sep 1995 12:26:48 +0200
  7. Received: by mpih17 (1.38.193.4/2.1) on NUNET
  8.      id AA04398; Mon, 4 Sep 1995 12:23:59 +0200
  9. Date: Mon, 4 Sep 1995 12:23:59 +0200 (METDST)
  10. From: Branko Collin <bcollin@mpi.nl>
  11. X-Sender: bcollin@mpih17
  12. To: Amos Discussion List <amos-list@access.digex.net>
  13. Subject: Re: Thanks
  14. In-Reply-To: <wSX6SMD261aez2@p22.sixpack.pfalz.org>
  15. Message-Id: <Pine.HPP.3.91.950904121825.4048C-100000@mpih17>
  16. Mime-Version: 1.0
  17. Content-Type: TEXT/PLAIN; charset=US-ASCII
  18. Status: RO
  19. X-Status: 
  20.  
  21. On Sun, 3 Sep 1995, Chris Hodges wrote:
  22.  
  23. > bcollin@mpi.nl (Branko Collin) wrote on 01.09.1995 some text under
  24. > the subject Re: Thanks. I can't leave this uncommentated ;-)
  25. > 
  26. > BC> If, say, we could gather about 20 programmers, we could make the biggest 
  27. > BC> Olympics based computer game ever!
  28. > 
  29. > !!! 20 programmers?!?! Even 4-6 coders would be more than enough
  30. > ;-)))
  31. > 
  32. > IMHO a team of about 30 people would be impossible to organize...
  33. > arguments are pre-coded ;-)
  34. > 
  35. > BC> I have been thinking a lot about this modular approach and it seems to be 
  36. > BC> the easiest for the programmers: this way they only have to 'obey' the 
  37. > BC> guidelines. This will eliminate a lot of the bugs expected from other 
  38. > BC> approaches. With a modular approach I mean this: All the modules and the 
  39. > BC> main program are separate, compiled Amos programs, only sharing one 
  40. > BC> graphics bank and one sound/music bank (and of course using proprietary 
  41. > BC> banks for each module).
  42. > 
  43. > I wouldn't do seperate compiled programs, I would simply use
  44. > procedures with a few global variables but the rest is completely
  45. > autarc.
  46. > 
  47. > BC> Obviously this method has a few drawbacks. The first that springs to mind 
  48. > BC> is that with twenty expected modules the whole programme may be over 2 
  49. > BC> Meg!
  50. > 
  51. > And it would switch to workbench after every module for a short
  52. > time...
  53. > 
  54. > BC> Another problem is the communication between the modules. Although Amos 
  55. > BC> can start (execute) other programs, I have found as yet no way of testing 
  56. > BC> wether a program has ended or not.
  57. > 
  58. > Because only ONE Amos program can run at a time, the other must have
  59. > already ended, if you gonna do a checking routine...
  60. > 
  61. > BC> Also we need to find a safe way to
  62. > BC> transfer scoring data to and from the main program (and/or to and from a 
  63. > BC> possible score keeping module).
  64. > 
  65. > T:Tempfile? ;)
  66.  
  67. Others mentioned using procedures too, and in that case it would indeed 
  68. be wiser to use only five or so programmers. That is why I suggest that 
  69. the programmers all deliver complete stand-alone products. This way the 
  70. only thing they have to know is the format of the scoring and player data 
  71. (i.e. Name, country, etc.). Of course there also needs to be a shared 
  72. look and feel, but implementation of it will not cause any bugs (I hope).
  73.  
  74. The control program can probably be written in another program, as it 
  75. does not need any fancy graphics or so.
  76.  
  77. ...................................     Lots of people talking     ....
  78. .       Branko Collin          .        Very few of them know         .
  79. .                              .       That the soul of a woman       .
  80. .   //  u249026@vm.uci.kun.nl  .           Was created below          .
  81. . \X/   bcollin@mpi.nl         .                                      .
  82. ................................. Led Zeppelin - Dazed and Confused  ..